A network service function is a middle box in a network that is responsible for a specific treatment of packets that it receives. The network service function can act on the received packets at one or multiple network/OSI layer(s) based on the intended functionality. There can be multiple such network service function middle boxes in a network providing different functionalities and/or multiple instances of the same functionalities. With the advent of NFV (Network Function Virtualization), the middle boxes are increasingly becoming virtualized, which helps in their flexible and on demand deployment in the network. Packets based on various policies, may be required to pass through a series of above-mentioned middle boxes. An ordered set of network service function middle boxes that packets must pass through is called service function chaining (also referred to as service chaining). Based on policy classification, a packet or a series of packets (also referred to as flow) might be required to follow a certain service chain. In a network, there can be multiple distinct service chains needed to realize various policy setting in a network. There can also be multiple instance of a service chain in order to balance load between instances of middle boxes that make up the service chains. It is also possible to have a middle box that is a part to multiple service chains.
A service chain may define an ordered set of service functions that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch. Steering the traffic through the middle boxes in a service chain requires configuration of network forwarding elements—such as switches, routers, and Software Defined Networking (SDN) switches—along the path of the service chain for each packet flow. The forwarding rules not only define the path taken by the packet flow in the network but also the middle boxes the packet flow has to enter in the service chain. All these forwarding rules that have to be configured per flow in network forwarding elements can lead to increased states in these elements and can affect their internal lookup time required to forward packets.
The conventional approach to implementing service chaining is by installing flow rules in the network forwarding elements for each packet flow, which may not be efficient and flexible. Solutions to solve these problems are all based on appending a header to the packet that identifies the service chain that the packet should follow.
Another solution involves IETF Service Function Chain (SFC) Encapsulation. The IETF RFC 7665 specifies a set of architectural components that compose a service chain enabled domain, such as the SFC encapsulation. This encapsulation intends to insert a new protocol header that encapsulates the packets and guides them through the service functions (middle boxes) within service chains. The header includes the Service Function Path ID, and can additionally carry metadata including data plane context information. Two proposals are currently available for the SFC encapsulation: Network Service Header (NSH) and Service Chain Header (SFH).
Moreover, the SFC encapsulation requires service functions (middle) boxes to understand the new protocol (process the header) or use a proxy in the switches to do the same. However, SFC encapsulation is not suitable for regular network packet forwarding. Such forwarding relies on overlay technologies (e.g. VLAN, VxLAN, GRE, MPLS).
Another solution, efficient mobile service chaining, provides a scalable solution for mobility in combination with service chaining. The solution is based on the concept of a new core network architecture where a location registry is kept up-to-date with the current location of each mobile device. The location registry can be implemented in several ways, including in a distributed fashion.
Packets are marked with one or more tags, where a tag has a name and a value. The combination of tags defines the service chain and destination for that packet. Aggregation is achieved by using the same tag for multiple flows and multiple devices, thereby limiting the number of entries in the service chain forwarding elements. Packets are tagged by one or more classifiers.
At a mobility event, at least one classifier gets updated such that packets for that device get marked with the same tag names, but where one or more tags have an updated value. The updated value reflects the new location of the mobile device. Forwarding elements can be configured on how packets with a specific tag are to be forwarded. Most forwarding elements of this configuration, and in typical cases all configurations, do not need to be updated upon mobility events. This keeps the control signaling towards the forwarding elements to a minimum.
The conventional way to realize service chains, especially in SDN, is by installing forwarding rules for all the flows in the network. However this approach is very inefficient and results in an explosion of forwarding rules in the network forwarding elements, which might also affect the look up times while forwarding a packet.
The approach of using a single field of fixed size to identify the chain (in both NSH and SCH the Service Function Path ID—SFP ID—has a fixed size), can be a limiting factor, especially in mobility scenarios where a solution able to scale well is needed. Current proposals (e.g., IETF) have the underlying assumption that the service chaining is done outside mobile networks (i.e. above mobile anchor points, and in 3GPP technologies, above the PDN Gateway). However, being able to perform service chaining within the mobile network segment can bring several benefits, such as: to bring service functions closer to the end-users (such as in the Mobile Service Routing in a Network Environment case) inside the mobile network. However, this brings the complexity associated to the mobile network, such as the signaling required to update the chain due to mobility events. If one considers establishing service chains on a per-user basis, this further increases the burden on the network forwarding elements. Other traditional encapsulation technologies (e.g. MPLS, VLAN) cannot provide the required scalability either since they do not support appending multiple tags for chain identification.